ソフトウェアアーキテクチャの基礎輪読会 18章
日付：2023/11/28
章：適切なアーキテクチャスタイルを選ぶ
調査者：naoya.icon
章のまとめ
どんな内容が書かれているか？
要約
場合による。
アーキテクチャにおけるトレンドの変遷(の要因)
過去からの観察
新しいアーキテクチャスタイルは過去の経験から得られた観察結果や問題点から生まれる
エコシステムの変化
ソフトウェア開発のエコシステムでは全てのものが常に変化している
新しいツールや機能のコレクションを提供してくれる
新しい能力
新しい能力はツールを置き換えるだけではなくて、全く新しいパラダイムに移行することがある
具体例
コンテナ技術(Docker)
加速
エコシステムは変化の速度も上がっている
新しいツールは新しいエンジニアリングプラクティスを生み出し、それが新しい設計や能力につながっている
ドメインの変化
ビジネスの継続的な進化や他者との合併などの要因によって常に変化している
技術の変化
技術が進化すると、それに応じて組織も少なからず変化する
収益に貢献する明らかなものから対応する
外部要因
組織内の変化
ソフトウェアの予算
経営状況
アーキテクチャスタイルの判断基準
アーキテクトが設計するもの
1. 指定されたあらゆるドメイン
2. システムを成功させるために必要なその他の全ての構造要素
ドメイン
アーキテクトはドメインの重要な側面を理解する必要がある
特に、運用特性
構造に影響を与えるアーキテクチャ特性
アーキテクトはドメインやその他の外部要因をサポートするために必要なアーキテクチャ特性を発見・解明する必要がある
データアーキテクチャ
アーキテクトは、データベース管理者とDB、スキーマ、その他のデータに関する関心ごとについて協力する必要がある
特に、新しいシステムが古いか、使用中のデータベースアーキテクチャと相互作用する必要がある場合
組織的な要因
具体例
クラウドベンダーのコスト
M＆Aを計画している場合、オープンなソリューションや統合しやすいアーキテクチャに傾倒する
プロセス、チーム、および運用上の関心ごとに関する知識
プロジェクト要因
開発プロセス
運用との相互作用(or 相互作用の欠如)
QAプロセス
ドメイン/アーキテクチャの同型性
問題領域によっては、アーキテクチャとトポロジーが一致するものがある
逆も然り
具体例
カスタマイズを必要とするシステム→マイクロカーネルアーキテクチャ
プラグインとして、カスタマイズできるから
多数の離散的な演算を必要とするシステム→スペースベースアーキテクチャ
多数の離散的なプロセッサーを提供しているから
高度にスケーラブルなシステム→❌モノリシックな設計
高度に結合されたコードベースで大量のユーザーの同時使用をサポートするのは難しいから
決めなければならないこと
モノリスor分散
アーキテクチャ特性のセットが１つだけで良い場合→モノリス
アーキテクチャ特性のセットを複数考慮する必要がある場合→分散
データをどこに置くか？
モノリス→単一もしくは、数個のリレーショナルDBを想定
分散→どのサービスがデータを保持するか決める必要がある
ワークフローを構築するためにアーキテクチャ全体でどのようにデータが流れなければならないかを考える必要がある
アーキテクトは設計をする際に、以下に気をつける必要がある
構造と振る舞いの両方を考慮する必要があること
より良い組み合わせを見つけるためにイテレーティブに設計すること
サービス間の通信スタイルは同期型 or 非同期型？
基本的には同期型が望ましい
設計
実装
デバッグ
非同期型が良い場合
スケーラビリティ
信頼性
パフォーマンス
非同期型のデメリット
データの同期性
デッドロック
競合状態
デバッグ
モノリスの事例
モジューラモノリス
単一のDBを持つ
単一量子としてデプロイされる
ドメイン中心のコンポーネントを構築
図18-1へ
マイクロカーネル
アーキテクチャ特性
カスタマイズ性
判断基準
ドメイン/アーキテクチャの同型性
図18--2
分散アーキテクチャの事例
naoya.icon 事例って書いたり、ケーススタディって書いたり、表現統一しろや💢
P102 8.7
P86 7.2.1
図18-3
Apendix
naoya.icon 結構みんなモノリスと分散で悩んでそう、線引きむずい...
マイクロサービスで新規に開発した結果、工数が増えトータルの納期が長くなり、パフォーマンスの低い分散デカ泥団子のシステムが出来上がる
naoya.icon 草
naoya.icon マイクロサービスアーキテクチャが銀の弾丸のように勘違いしてる人は多いのか。笑
kiri.icon例え草
質疑応答